afl
插桩
64kb的共享内存来储存
界面解析
① Process timing:Fuzzer运行时长、以及距离最近发现的路径、崩溃和挂起经过了多长时间。
② Overall results：Fuzzer当前状态的概述。
③ Cycle progress：我们输入队列的距离。
④ Map coverage：目标二进制文件中的插桩代码所观察到覆盖范围的细节。
⑤ Stage progress：Fuzzer现在正在执行的文件变异策略、执行次数和执行速度。
⑥ Findings in depth：有关我们找到的执行路径，异常和挂起数量的信息。
⑦ Fuzzing strategy yields：关于突变策略产生的最新行为和结果的详细信息。
⑧ Path geometry：有关Fuzzer找到的执行路径的信息。
⑨ CPU load：CPU利用率
快速起fuzz的例子
输出路径的文件夹解析
一些问题
优化
并行fuzz
可以用afl-whatsup <output目录>查看状态
-M进行确定性测试（deterministic ），即对输入文件进行一些特殊而非随机的的变异
-S进行完全随机的变异。
获取cpu的个数
跨系统fuzz
https://github.com/MartijnB/disfuzz-afl
提升效率
llvm模式会更快
持久模式
两者相结合提速2.8倍
大海捞针
减少单个输入的大小
移除执行相同代码的输入文件
给字典（关键字）
去掉校验代码
一个开源，一个不开源的同类软件
crash 处理
找到那里导致的崩溃
Sanitizers
作者自己的方法
afl自带的一些工具
预处理
移除执行相同代码的输入文件——afl-cmin
减小单个输入文件的大小——afl-tmin
使用afl-showmap跟踪单个输入的执行路径，并打印程序执行的输出、捕获的元组（tuples），tuple用于获取分支信息，从而衡量衡量程序覆盖情况
fuzz状态查看
并行fuzz时，afl-whatsup工具可以查看每个fuzzer的运行状态和总体运行概况，加上-s选项只显示概况，其中的数据都是所有fuzzer的总和。
afl-gotcpu工具可以查看每个核心使用状态
afl-plot绘制各种状态指标的直观变化趋势图
崩溃处理
afl-fuzz -C - crash exploration mode (the peruvian rabbit thing).
AFL源码的experimental目录中有一个名为triage_crashes.sh的脚本，可以帮助我们触发收集到的crashes。
https://github.com/bnagy/crashwalk 工具基于gdb的exploitable插件
afl-collect，它也是afl-utils套件中的一个工具，同样也是基于exploitable来检查crashes的可利用性。它可以自动删除无效的crash样本、删除重复样本以及自动化样本分类。
afl-collect -j 8 -d crashes.db -e gdb_script ./afl_sync_dir ./collection_dir – /path/to/target –target-opts
其他人开发的工具
https://gitlab.com/rc0r/afl-utils
代码覆盖率
GCOV随gcc一起发布，所以不需要再单独安装，和afl-gcc插桩编译的原理一样，gcc编译时生成插桩的程序，用于在执行时生成代码覆盖率信息。
另外一个工具是LCOV，它是GCOV的图形前端，可以收集多个源文件的gcov数据，并创建包含使用覆盖率信息注释的源代码HTML页面。
最后一个工具是afl-cov，可以快速帮助我们调用前面两个工具处理来自afl-fuzz测试用例的代码覆盖率结果。
1 | 还是以Fuzz libtiff为例，计算Fuzzing过程的代码覆盖率流程如下： |
